I. Technical Field
This invention pertains to the handling of data packets in telecommunications, including but not limited to performance of operations such as encryption and compression of data packets in telecommunications.
II. Related Art and Other Considerations
Networking systems such as telecommunications systems are typically divided into layers. For example, the International Organization for Standardization (ISO) has developed an Open Systems Interconnection (OSI) networking model, also known as the OSI seven layer model and described in OSI 7498, which is incorporated herein by reference. The layers of the seven-layer OSI model (illustrated in FIG. 38) are as follows: (from bottom or first layer to top or seventh layer): physical layer; data link layer (or “link” layer); network layer; transport layer; session layer; presentation layer; and application layer. As used herein, a “model layer” is a layer comparable or analogous to a Model layer, regardless of whether specifications of/for the network employing such model layer explicitly refer to the OSI model or not. Within each model layer, the functionality(ies) of each layer may be implemented by one or more entities or functional units. In this sense, within each model layer there may be various functional layers, such as compression, encryption, and checksum functional layers, for example.
Due to the tremendous success of the Internet, it has become a challenging task to make use of the Internet Protocol (IP) over all kinds of links. IP protocols employ IP packets, the IP packets typically having a payload which carries the substantive user data, as well as a “header” usually appended at the beginning of the IP packet. The header generally carries information helpful for processing of the IP packet through one or more layers of the OSI model.
Because of the fact that the headers of the IP protocols are rather large, it is not always a simple task to use IP protocols for narrow band links, for example cellular links. As an example, consider ordinary speech data transported by the protocols (IP, UDP, RTP) used for Voice-over-IP (VoIP), where the header may represent about 70% of the packet-resulting in a very inefficient usage of the link.
A. Header Compression: Overview
Header compression is an important component to make IP services over wireless, such as voice and video services, economically feasible. The term header compression (HC) comprises the art of minimizing the necessary bandwidth for information carried in headers on a per-hop basis over point-to-point links. Header compression solutions have been developed by the Robust Header Compression (ROHC) Working Group of the IETF to improve the efficiency of such services.
Header compression techniques in general have a more than ten-year-old history within the Internet community; several commonly used protocols exist such as RFC 1144 [Van Jacobson, Compressing TCP/IP Headers for Low-Speed Serial Links, IETF RFC 1144, IETF Network Working Group, February 1990], RFC 2507 [Mikael Degermark, Björn Nordgren, Stephen Pink; IP Header Compression, IETF RFC 2507, IETF Network Working Group, February 1999]; and RFC 2508 [Steven Casner, Van Jacobson, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links; IETF RFC 2508, IETF Network Working Group, February 1999], all of which are incorporated herein by reference.
Header compression takes advantage of the fact that some fields in the headers are not changing within a flow, or change with small and/or predictable values. Header compression schemes make use of these characteristics and send static information only initially, while changing fields are sent with their absolute values or as differences from packet to packet. Completely random information has to be sent without any compression at all.
Header compression is often characterized as an interaction between two state machines, one compressor machine and one decompressor machine, each maintaining some information related to flows being compressed in a context.
A compression context contains and maintains relevant information about past packets, and this information is used to compress and decompress subsequent packets. As explained in Carsten Bormann, et al. RObust Header Compression (ROHC). Framework and four profiles. RTP, UDP, ESP and uncompressed. IETF RFC 3095, April 2001 (incorporated herein by reference):                “The context of the compressor is the state it uses to compress a header. The context of the decompressor is the state it uses to decompress a header. Either of these or the two in combination are usually referred to as “context”, when it is clear which is intended. The context contains relevant information from previous headers in the packet stream, such as static fields and possible reference values for compression and decompression. Moreover, additional information describing the packet stream is also part of the context, for example information about how the IP Identifier field changes and the typical inter-packet increase in sequence numbers or timestamps.”        
A challenging task is to keep the compressor and decompressor states, called contexts, consistent with each other, while keeping the header overhead as low as possible. There is one state machine for the compressor, and one state machine for the decompressor. The compressor state machine directly impacts the level of compression efficiency, as it is an important part of the logic controlling the choice of compressed packet type to be sent; the purpose of the decompressor state machine is mainly to provide the logic for feedback (if applicable) and to identify the packet types for which decompression may be attempted.
A packet that provides the means for the decompressor to verify successful decompression is a context-updating packet. Because decompression can be verified, this type of packet can update the context. For ROHC, context-updating packet types carry a Cyclic Redundancy Code (CRC) within their format; this is a checksum calculated over the original uncompressed header. This CRC is used to verify successful decompression of each packet; when successful, the context can be updated.
A packet that relies on other means to guarantee successful decompression—i.e. a packet format does not provide the means for the decompressor to verify successful decompression, and that only carries the information necessary for the decompression itself, is a self-contained packet. These packets do not update the context.
Header compression is uses a Sequence Number to uniquely identify individual packets. Fields in header compression are normally compressed based on a function of the Sequence Number (SN). This SN number can be either derived from the protocol being compressed (e.g. RTP SN), or generated by the compressor. Within this document, such sequence number is referred to as the Master Sequence Number (MSN) when the distinction between both is irrelevant.
Early header compression profiles were designed with the assumption that the channel between the compressor and the decompressor will not reorder the header-compressed packets; the channel is required to maintain packet ordering for each compressed flow. This assumption was motivated because the channels initially considered as potential candidates to use ROHC did guarantee in-order delivery of packets; this assumption was useful to improve compression efficiency and the tolerance against packet loss, objectives that were ranked highest on the requirement list at the time.
RoHCv2 profiles currently being developed will handle out-of-order delivery between compression endpoints within the compression protocol and encoding methods itself, among other improvements.
A number of different types of compression can be used above the link layer. These include payload compression (see, e.g., Pereira, R., IP Payload Compression Using DEFLATE, IETF RFC 2394, December 1998; and Friend, R. et R. Monsour, IPPayload Compression Using LZS, IETF RFC 2395, December 1998, incorporated herein by reference), signaling compression (see, e.g., Price, R. et al., Signalling Compression (SigComp), IETF RFC 3320, January 2003, incorporated herein by reference), header removal and regeneration, and header compression. Concerning header compression, see, e.g., Van Jacobson, Compressing TCP/IP Headers for Low-Speed Serial Links, IETF RFC 1144, IETF Network Working Group, February 1990; Mikael Degermark, Björn Nordgren, Stephen Pink; IP Header Compression, IETF RFC 2507, IETF Network Working Group, February 1999; Steven Casner, Van Jacobson, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links; IETF RFC 2508, IETF Network Working Group, February 1999; Koren, T., Casner, S., Geevarghese, J., Thompson B. and P. Ruddy, Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering, IETF RFC 3545, IETF Network Working Group, July 2003; Carsten Bormann, et al. RObust Header Compression (ROHC). Framework and four profiles. RTP, UDP, ESP and uncompressed. IETF RFC 3095, April 2001; Jonsson, L. and G. Pelletier, RObust Header Compression (ROHC). A compression profile for IP, IETF RFC 3843, June 2004; Pelletier, G., RObust Header Compression (ROHC). Profiles for UDP-Lite, IETF RFC 4019, April 2005; and Pelletier, G., Sandlund, K. and L. Jonsson, Robust Header Compression (ROHC). A Profile or TCP/IP, Internet Draft (work in progress), <draft-ietf-rohc-tcp-11.txt>, January 2006. All references listed in this paragraph are incorporated herein by reference. Any of these types of compression may be designed to make use of sequence numbers and checksums.
Other optimizations, such as other types of compression, can also be used to further increase the performance of bandwidth-limited systems.
B. Header Compression: Verification
Robust header compression uses a checksum (CRC) calculated over the compressed header (e.g. within initialization packets) or over the uncompressed header (e.g. in compressed packets). This is used to verify correct decompression at the decompressor. More specifically, as one example, header compression normally uses a checksum to verify the outcome of its decompression attempts. It can be a checksum calculated over the uncompressed state of the information being compressed, or it can be a checksum calculated over the information sent between compressor and decompressor, i.e. either of the compressed information, the uncompressed information or the compression protocol information, or any combination thereof.
Similarly, a Frame Checksum Sequence (FCS) is often used before the deciphering process, in order to ensure that no information delivered to the deciphering algorithm can lead to an incorrect ciphering context.
Undetected residual errors may lead to loss of synchronization to any of the functions discussed above, depending on the algorithm used.
A header compressor can use the secure reference principle to ensure that context synchronization between compressor and decompressor cannot be lost due to packet losses. The compressor obtains its confidence that the decompressor has successfully updated the context from a context-updating packet based on acknowledgements received by the decompressor. However, most packet types used with the secure reference principle are self-contained and thus not meant to update the context.
The compressor normally updates its compression context only after receiving acknowledgements from the decompressor for a context updating packet (identified using the MSN in the feedback message).
The decompressor normally updates its context after verifying the outcome of the decompression, using the cyclical redundancy check (CRC) carried within the compressed header (when present in the packet format, not always true when operating using the secure reference principle). Subject to rate limitation, the decompressor normally acknowledge the update to the compressor.
C. Security/Ciphering
The evolution and design using new architectural models tend to reduce the number of nodes involved in the transmission path, and to use openly standardized interfaces. This in turn modifies the traditional separation between functions, as well as creating new trust models with respect to security. While security is often seen in the Internet paradigm as an end-to-end function between communicating hosts, security mechanisms are often found in lower model layers to address low-level security issues.
In terms of security, encryption of packet data flows often requires the sender and the receiver to maintain cryptographic state information. This information is often referred to as a cryptographic context.
Cryptographic keys can be part of this context, e.g. one “session” key may be used directly by the cryptographic transform while another “master” key can be used to derive the session key. The master key is normally given by a key management protocol in a secure way. Other parameters found in the context are often e.g. an identifier for the encryption algorithm, indicators for the session, counters, length parameters for keys, etc. Many of these parameters are specific to the active cryptographic transform.
Some algorithms derive the session key to use for a packet based on the sequencing information associated with the packet. For example, Secure Real-Time Reference Protocol (SRTP) (see FIG. 1) derives an index for the packet based on the RTP sequence number carried within the packet. SRTP is an OSI application layer protocol, meant to provide an end-to-end security layer to real-time applications using the RTP/RTCP protocols, as illustrated in FIG. 2. SRTP is described, e.g., in Baugher M. et al., The Secure Real-time Transport Protocol (SRTP), IETF RFC 3711, March 2004, incorporated herein by reference. It is herein acknowledged that there are limitations to the derivation of the key index, as the derivation of correct value and the updating of the cryptographic context is sensitive to larger packet reordering as well as to residual bit errors. While the amount of reordering mentioned is in the order of 2^15 packets and is not likely to occur, this highlights the possible impacts of undetected bit errors being presented to the security layer where an erroneous packet may mistakenly update the crypto context with an index in the wrong interval, and disrupt deciphering of subsequent packets.
These algorithms maintain this sequencing information as part of the cryptographic context, and the correct indexing and update to this information must thus be robust between ciphering endpoints. The exact correct sequencing must be known in order to use the correct deciphering key. As opposed to header compression with RoHC, most often the cryptographic context is updated without any form of verification of the success of the operation. This normally requires robust mechanisms to ensure that sequencing is maintained properly. Examples of such cryptographic transforms, and how they operate encryption or decryption once the session key is known, can be found in SRTP.
The ciphering function thus requires that the order in which the encrypted packets are received is the same as the order in which they were sent, or at least that this information can be derived, in order to pick the correct deciphering key. Otherwise, the ciphered data will not be correctly deciphered, and potentially the cryptographic context will become unsynchronized, thus propagating the errors to subsequent packets.
D: Compression: Synchronization
FIG. 3 shows a typical example of a compressor (upper part) and a decompressor (lower part) operating using the secure reference principle. Compressed packets are exchanged over time (Sequence axis), and the Secure Reference (SR) LSB sliding window is updated following specific events. Note that the sliding window may contain more than one value at certain moments, but there is always only one that is the secure reference used for compression and decompression of a specific field.
The objective of the compression peers is to always stay synchronized regarding what reference is used for the compression/decompression of a particular packet. In particular, the following applies and is reflected in the FIG. 3.                The decompressor can only verify the successful decompression of context-updating packets (packets that can update the secure reference).        The decompressor cannot verify the successful decompression of a self-contained packet (a packet that does not update the secure reference).        The compressor updates its sliding window of secure references when an acknowledgement is received from the decompressor. Previous reference(s) (acknowledged and/or unacknowledged) are removed from the window, and only the latest acknowledged one is kept as the secure reference.        The decompressor updates its sliding window of secure references when a packet is received for which the LSBs are less than earlier packets, indicating that it has been compressed with the reference that the decompressor has previously acknowledged. Only the latest reference for which an acknowledgement was sent is then kept as the secure reference.        
According to the state of the art when using the “optimistic approach”, the compressor always updates its context. This is because all packets that are sent contain a checksum calculated of the uncompressed header. This checksum is used by the decompressor to verify the outcome of the decompression process. When successful, the decompressor updates its context.
According to the state of the art for updating the cryptographic context, the cryptographic context normally gets updated with the highest sequence number seen when deciphering a packet, as well as with a roll-over counter and other parameters, for each packet that it processes. The cryptographic context update normally relies heavily on guarantees of in-order delivery, very low probability for residual bit errors when sequencing information and other ciphering is carried over a link; it normally has no means to verify the outcome of the deciphering process.
E. Radio Access Network: Overview
In a typical cellular radio system, wireless user equipment units (UEs) communicate via a radio access network (RAN) to one or more core networks. The user equipment units (UEs) can be mobile stations such as mobile telephones (“cellular” telephones) and laptops with mobile termination, and thus can be, for example, portable, pocket, hand-held, computer-included, or car-mounted mobile devices which communicate voice and/or data with radio access network. Alternatively, the wireless user equipment units can be fixed wireless devices, e.g., fixed cellular devices/terminals which are part of a wireless local loop or the like.
The radio access network (RAN) covers a geographical area which is divided into cell areas, with each cell area being served by a base station. A cell is a geographical area where radio coverage is provided by the radio base station equipment at a base station site. Each cell is identified by a unique identity, which is broadcast in the cell. The base stations communicate over the air interface (e.g., radio frequencies) with the user equipment units (UE) within range of the base stations. In the radio access network, several base stations are typically connected (e.g., by landlines or microwave) to a radio network controller (RNC). The radio network controller, also sometimes termed a base station controller (BSC), supervises and coordinates various activities of the plural base stations connected thereto. The radio network controllers are typically connected to one or more core networks.
One example of a radio access network is the Universal Mobile Telecommunications (UMTS) Terrestrial Radio Access Network (UTRAN). The UMTS is a third generation system which in some respects builds upon the radio access technology known as Global System for Mobile communications (GSM) developed in Europe. UTRAN is essentially a radio access network providing wideband code division multiple access (WCDMA) to user equipment units (UEs). The Third Generation Partnership Project (3GPP) has undertaken to evolve further the UTRAN and GSM-based radio access network technologies.
The core network has two service domains, with an RNC having an interface to both of these domains. The Universal Mobile Telecommunications (UMTS) Terrestrial Radio Access Network (UTRAN) accommodates both circuit switched and packet switched connections. In this regard, in UTRAN the circuit switched connections involve a radio network controller (RNC) communicating with a mobile switching center (MSC), which in turn is connected to a connection-oriented, external core network, which may be (for example) the Public Switched Telephone Network (PSTN) and/or the Integrated Services Digital Network (ISDN). On the other hand, in UTRAN the packet switched connections involve the radio network controller communicating with a Serving GPRS Support Node (SGSN) which in turn is connected through a backbone network and a Gateway GPRS support node (GGSN) to packet-switched networks (e.g., the Internet, X.25 external networks).
There are several interfaces of interest in the UTRAN. The interface between the radio network controllers (RNCs) and the core network(s) is termed the “Iu” interface. The interface between a radio network controller (RNC) and its base stations (BSs) is termed the “Iub” interface. The interface between the user equipment unit (UE) and the base stations is known as the “air interface” or the “radio interface” or “Uu interface”.
FIG. 4 shows an example of a traditional architecture, here exemplified using the UTRAN architecture. Of particular interest in the UTRAN architecture is the traditional separation between functionalities into different nodes: the RNC handles sequencing when lossless relocation is supported (optional), thus adding an overhead for one sequence number. The ciphering occurs in the NodeB, and requires in-order delivery of each SDUs to maintain the ciphering context. In order to ensure that the ciphering does not loose synchronization, a L2 Frame Checksum Sequence (FCS) is normally used, adding additional octets for transmission over the air interface.
The Hybrid-ARQ mechanism requires reliable detection of bit error during transmission of individual blocks, as it must detect transmission failures for RLC PDU in order to request a retransmission. Thus, it is assumed that the rate of residual bit error rate (BER) after the H-ARQ is very low.
F. System Evolution: Overview
The Third Generation Partnership Project (3GPP) is also specifying the long-term evolution of third generation cellular systems to meet demands for, e.g., higher user bit rate. In September 2006, 3GPP finalized a study item called Evolved UTRA and UTRAN. The purpose of the study was to define the long-term evolution (LTE) of 3GPP access technology for the future. Also undertaken is a study for System Architecture Evolution (SAE) whose objective is development of a framework for an evolution or migration of the 3GPP system to a higher-data rate, lower-latency, packet-optimized system that supports multiple radio access technologies.
The evolved UTRAN comprises evolved base station nodes, e.g., evolved NodeBs or eNBs, providing the evolved UTRA U-plane and C-plane protocol terminations toward the user equipment unit (UE). As shown in FIG. 5, the eNB hosts the following functions: (1) functions for radio resource management (e.g., radio bearer control, radio admission control), connection mobility control, dynamic resource allocation (scheduling); (2) mobility management entity (MME) including, e.g., distribution of paging message to the eNBs; and (3) User Plane Entity (UPE), including IP Header Compression and encryption of user data streams; termination of U-plane packets for paging reasons, and switching of U-plane for support of UE mobility.
The eNBs are connected with each other by means of an X2 interface. The eNBs are also connected by means of an S1 interface to the Evolved Packet Core (EPC). The S1 interface supports a many-to-many relation between an access gateway (aGW) in the packet core and the eNBs. The S1 interface provides access to the Evolved RAN radio resources for the transport of user plane and control plane traffic. The S1 reference point enables MME and UPE separation and also deployments of a combined MME and UPE solution.
As seen in FIG. 5, of particular interest in the current proposal for the SAE/LTE architecture is the removal of the RNC. Removal of the RNC node results in the fact that the ciphering function and the PDCP function, which hosts the header compression function, are now located in the same node, e.g., in the aGW or in the eNB. Both the ciphering and the PDCP functions terminate into the User Equipment (UE) on the other end. In other words, the interface between the aGW node and the eNB node is deemed to be untrusted. Untrusted means that the eNB can be physically tampered with. The eNB is normally in a remote location, and if the eNB gets compromised, much user information could potentially be misappropriated. The S1 interface thus requires that ciphering be applied to the user traffic, and this propagates up to the UE. A secure tunnel over the S1 interface would not solve the problem of trust of the eNB node.
One issue with respect to reordering between ciphering and/or PDCP entities is that the S1 interface or the air interface (H-ARQ) may (when PDCP is in aGW) produce out-of-order packets. As ciphering requires correct sequencing information, additional overhead for sequencing must be maintained and transmitted over the air interface. In case lossless relocation is to be supported, additional sequencing overhead may be required in the PDCP as well.
FIG. 6 shows an example third party proposal with respect to the PDCP functions and SAE/LTE architecture. PDCP functions may also be located in the eNB in the SAE/LTE architecture, in which case the same issues apply there as well.
G. Multiple Independent Layers of Functionality
As indicated previously, within each model layer there may be a layering of functionality(ies) into separated, multiple independent functional layers. The creation of multiple functional layers within a model layer creates considerable overhead. Traditionally, this has been necessary as the functions where often separated into different physical nodes, as in the example of the evolved UTRAN (E-UTRAN) architecture briefly described above.
In view of the conventional layered technology, and with respect to model layer 2 ciphering and current E-UTRAN/SAE/LTE architecture, each layered function (such as ciphering) uses its own separate mechanism to maintain sequencing and perform encryption, possibly coupled with PDCP sequencing independently of other functions such as header compression. Detection of residual error above the H-ARQ protocol is often necessary, to ensure that correct cryptographic context is maintained; this is also independent of potential verification mechanism from other layers.
The state-of-the-art in terms of header compression is RoHC, Carsten Bormann, et al. RObust Header Compression (ROHC). Framework and four profiles. RTP, UDP, ESP and uncompressed. IETF RFC 3095, April 2001; Pelletier, G., Sandlund, K. and L. Jonsson, The Robust Header Compression (ROHC) Framework, Internet Draft (work in progress), <draft-ietf-rohc-rfc3095bis-framework-00.txt>, December 2005. RoHC currently uses its own sequence number and its own checksum. The same applies to state-of-the-art ciphering that relies on model layer 2 sequencing and checksums. RoHC does not currently handle reordering, although this is being addressed. In terms of the type of encryption that is of interest to this idea, SRTP is the state-of-the-art; however, it operates at the OSI application layer and not in combination with header compression.
In view of the conventional layered technology, ciphering uses its own separate mechanism to maintain sequencing, possibly coupled with PDCP sequencing independently of header compression, and where residual error detection above the H-ARQ protocol is required to ensure robust selection/derivation of the session key from the cryptographic context for the ciphering process, and is independent of the header compression function. Ciphering and header compression have always been handled independently of one another. One possible reason is that often some functions operate on the connection (e.g. ciphering, reordering), independently and unaware of the different flows they are processing and forwarding to other layers other than (possibly) common requirements from that layer itself (e.g. based on QoS requirements), as illustrated in example manner in FIG. 7.
FIG. 8 illustrates, in example fashion, a problem now addressed. Even in an LTE/SAE type system, the layering of functions even within a same node results in significant overhead. For the overhead of the lower layer, Table 1 below shows the layer 2 function and corresponding overhead (in octets).
TABLE 1Layer 2 FCS:3-4octets (handles bit errors)Layer 2 (ciphering):2octets (reordering + ciphering key)Layer 2 PDCP SN:2octets (lossless relocation − PDCPSeqNum PDU)Total overhead:7+octets
What is desired, therefore, and an object of the present invention, are one or more of a node, apparatus, system, method, or technique for reducing overhead associated with model layer 2 functions (e.g., link layer functions).